Introduction to gRPC
What gRPC is and how it fits in an API context
gRPC is a high-performance remote procedure call (RPC) framework that was developed by Google. It allows for efficient communication between services, using a strongly-typed binary protocol over HTTP/2.
In the API context, gRPC can be used to define and expose APIs in a language-agnostic way. It provides a flexible and efficient way for microservices to communicate with each other, enabling communication between services regardless of the programming languages they are written in.
gRPC uses a schema file to define the interface of the API, and automatically generates client and server code in a variety of languages (such as C++, Java, Python, Go, and more) based on this schema. This makes it easy to write clients and servers for your API in a variety of programming languages
gRPC provides both synchronous and asynchronous communication mechanisms between the client and server.
On the server side, the service methods declared in the API are implemented by the server, which runs a gRPC server to manage client requests. The gRPC infrastructure handles the processing of incoming requests, performs the necessary service operations, and encodes the responses before returning them to the client.
On the client side, a local object called a stub (sometimes referred to as a client) is created that implements the same methods as the service. The client can simply call these methods on the stub object, which then packages the call's parameters into the appropriate protocol buffer message type, sends the request to the server, and returns the server's response encoded in a protocol buffer message.
gRPC Pros
Performance
Performance is given by a number of reasons.
- First, the serialization used ; protobuf is a high-performance binary message format used to serialize gRPC messages. Both server and client can serialize Protobuf messages quickly, resulting in small message payloads. This is particularly valuable in situations with limited bandwidth, such as mobile applications.
- Second - related to the protocol
gRPC is designed for HTTP/2, a major revision of HTTP that provides significant performance benefits over HTTP 1.x:
- Binary framing and compression. HTTP/2 protocol is compact and efficient both in sending and receiving.
- Multiplexing of multiple HTTP/2 calls over a single TCP connection. Multiplexing eliminates head-of-line blocking.
Interoperability
Streaming
Deadline/timeouts and cancellation
Allows clients to specify a maximum time for an RPC to finish.
Security
Drawbacks
- Broadcast real-time communication : although it supports real-time communication via streaming, a gRPC call won't be able to send a message to clients out of the box. It will need first the client to initiate a comunication, and then it will be able to stream.
For example in a chat room scenario where new chat messages should be sent to all clients in the chat room, each gRPC call is required to individually stream new chat messages to the client. SignalR is a useful framework for this scenario since it has the concept of persistent connections and built-in support for broadcasting messages.
- Browser accessible APIs: it's not fully supported in the browser. gRPC-Web can offer browser support, but it has limitations and introduces a server proxy.
- Limited browser support -
gRPC on ASP.NET Core offers two browser-compatible solutions:
gRPC-Web
gRPC transcoding
Not human readable - While Protobuf is efficient to send and receive, its binary format isn't human readable. Protobuf requires the message's interface description specified in the .proto file to properly deserialize. Now we have the means to decode the binary messages. Tools like Postman, grpcURL are able to assist The built-in JSON conversion provides an efficient way to convert Protobuf messages to and from human readable form when debugging.
gRPC vs RESTful/HTTP APIs
| Feature | gRPC | HTTP API |
|---|---|---|
| Contract | Required (.proto) | Optional |
| Protocol | HTTP/2 | HTTP/2 & 1 |
| Payload | Protobuf (small, binary) | JSON (large, human readable) |
| Prescriptiveness | Strict specification | Strict specification |
| Streaming | Client, server, bi-directional | Client, server |
| Client code-generation | yes | OpenAPI + third-party tooling |
| Security | Transport (TLS) | Transport (TLS) |
| browser support | No (requires grpc-web) | Yes |
gRPC vs WCF
!!Open discussion!!
Scenarios where gRPC can shine
- Microservices: gRPC is designed for low latency and high throughput communication. gRPC is great for lightweight microservices where efficiency is critical.
- Point-to-point real-time communication: gRPC has excellent support for bi-directional streaming. gRPC services can push messages in real-time without polling, or real-time services that need to handle streaming requests or responses
- Polyglot environments: gRPC tooling supports all popular development languages, making gRPC a good choice for multi-language environments. -Network constrained environments: gRPC messages are serialized with Protobuf, a lightweight message format. A gRPC message is always smaller than an equivalent JSON message.
- Inter-process communication (IPC): IPC transports such as Unix domain sockets and named pipes can be used with gRPC to communicate between apps on the same machine.
- Background jobs (Windows service, CRON, etc.) connected to one or more web service(s), which is purely a back-end scenario; gRPC could replace REST or SOAP web services
Who uses it?
Google has been using a lot of the underlying technologies and concepts in gRPC for a long time. The current implementation is being used in several of Google’s cloud products and Google externally facing APIs. It is also being used by Square, Netflix, CoreOS, Docker, CockroachDB, Cisco, Juniper Networks and many other organizations and individuals
gRPC is a Cloud Native Computing Foundation (CNCF) project.
Other resources:
Official Repo: Official Repo: Silentorbit grpc-browser http2